Data Intake Family Records Overview

provides the Group Customer with the ability to process intake files of data specific to employee/sponsor changes/additions. The data intake files include both updates and new records for employee and dependent data. OIGPA will process the batches of data coming in from the Group Customer. The information is handled via a standardized format known as Family Neutral Recordor FNR. The files are sent periodically by the Group Customer (timing and preferences designated at the time of Group Customer set up/implementation) to the carrier in various file formats. Data Intake can be handled within the system by directly inserting the records into the database or via webservice request via AsFile.

How it Works

Each Family Record contains the information that needs to be processed on an employee and dependents for a Group Customer. The file will contain an identifier for the Group Customer to easily identify the employee and related dependents for the Group Customer. The IDs are used to identify the file type from the Group Customer Data Intake Preferences (typically identified on the Group Customer Screen) and the identification of the file type being received. See Types for more information.

Family Records processed for the Group Customer are handled via the Group Customer Activity Group. Please see Activity Group for details on the screen layout, processing, undo-redo, and navigation.

Information Received

The data in the files may result in changes such as the following:

  • Adding a new employee to OIGPA (Personal and/or Employment Data)
  • Changing the Employee's elected coverage
  • Enrolling/Adding a dependent or spouse to coverage
  • Auto-Canceling coverage for an employee
  • Updating employee information (hours worked, status, salary)

Types of Files

There are many different types of files incoming for the Group Customer. Each file may additionally have different record types.

The typical types of files received are:

Participation: This file contains only eligible members who have elected to participate in coverage. The Participation file contains records for both the participant and their coverage Enrollment. OIGPA will simply assign the employee to a Class and enroll them in coverage without validation of eligibility. Eligibility is handled via a different type of file. For the Participation file, the following data is stored/processed:

  • Member information stored (client / address)
  • Employment information stored (salary, placement/position in the company)
  • Employee's dependents stored (client/address)
  • Employee and dependents are enrolled in selected coverage(s) (policy, segments)
  • Employee's placement in the applicable Class (legacy structure, billing, etc...)

Note: When receiving a Participation file, OIGPA does not have to run plan eligibility determination for the members in the file.

EligibilityThis file contains only members from the Group Customer who qualify or are eligible. There are subcategories associated with this file type. For both subcategories/sub-types of files, OIGPAwill need to calculate the class based on the information provided. The end result being the placement of the employees into the their respective plan eligibility class. The subcategories or sub-types of files for Eligibility are:

  • Eligibility with the Class specified. The Group Customer is informing the Carrier what class the employee is eligible for and the file will contain both employee information and the intended eligibility class.
  • Eligibility without Class specified. For this purpose, the file only contains the employee information for which class determination will be based.

Population This file contains all or a subset of the employees for a Group Customer regardless of whether they are eligible or not. No eligibility determination is being made at this point by the Group Customer. This file can be considered Universal. OIGPA will need to calculate eligibility as this file only places the employee in the class for the system. A new employee sited on the Population file may:

  • Member information may be stored (client/address)
  • Employment information may be stored (salary, grade/position)
  • Employee placement into a class (union, non-union, management, non-management)

There are two different types of records that can be received on any of the above listed file types:

  • Changes only
  • Full Record

Changes Only: This record type contains data changes as they pertain to information that currently exists in OIGPA. OIGPA will not need to calculate the changes for the Family Record as the Group Customer is sending the changes only (the ending record result is the change). For example, a completely populated or complete Family Record for a brand new employee or a partially populated Family Record representing the updated information for an existing employee or participant.

Full Record: This record will contain fully populated Family Records only. OIGPAmust calculate changes for each Family Record in the file received. Upon validation against the database for the existence of the record, the result could be the following:

  • A new record for the employee must be added to OIGPA
  • An employee record exists, but the record must be updated
  • An employee records exists in OIGPA but not on the file received and therefore, should be removed (canceled) from OIGPA (subject to Group Customer preferences).

File Type Processes

The following table outlines the different file type combinations and expected processes that will occur with OIGPA.

  • Employee information includes client data, address information, relationship (to the Group Customer), and dependent changes/updates/additions including client and address information.
  • Eligibility can result in additions to the Class Membership.
  • Participation can include updates/additions to coverage or specifically, Segments.
File Type Record Type Processing in OIGPA
Participation Changes Only
  • Store Employee/Dependent information
  • Store Class(es)
  • Enroll in Coverage(s)
  • Update Coverage(s)
Participation Full Record
  • Calculate changes
  • Store Employee/Dependent information
  • Store Class(es)

If currently NOTenrolled:

  • Enroll in Coverage(s)
  • Update Coverage(s)
  • Cancel if record missing from file

If current enrolled:

  • Update Employee/Dependent information
  • Update Class(es)
  • Update Coverage(s)
Eligibility Changes Only
  • Calculate Eligibility in OIGPA
  • Validate Eligibility changes
  • Store Employee/Dependent information
  • Store Class(es)
Eligibility Full Record
  • Calculate Changes in OIGPA
  • Calculate Eligibility
  • Validate Eligibility changes
  • Store Employee/Dependent information
  • Store Class(es)
  • Cancel if record missing from file
Population Changes Only
  • Calculate Eligibility

If Eligible:

  • Validate Eligibility Changes in OIGPA
  • Store Employee/Dependent information
  • Store Class(es)
Population Full Record
  • Calculate Changes in OIGPA
  • Calculate Eligibility

If Eligible:

  • Validate Eligibility Changes
  • Store Employee information
  • Store Class(es)

How it Works

Data Intake Receipt and Loading

Each of the individual records received for processing will contain a Group Customer Identifier and Member ID that can be used to uniquely identify the member for the Group Customer. The Member ID can be an Employee ID or a Tax ID number, or a combination of both designated by the Group Customer.

The first part of the receiving process will begin at the loading of the file. Each record will be loaded individually and the file will be present in a 'Loading' status. An expected number of records will be provided for each file that defines the number of / quantity of records expected to be on the actual file received. Once the last record on the file is delivered, the calling system will indicate the entire file is ready and at that time the file will go into a 'Pending' status. Activity Group screen tracks the number of expected versus number of received, active, and pending records.

The Data Intake Profile Definition Rule will be used to define the set up of the incoming file. The Rule is also used to display the fields on the Intake Profile Screen and allows for validations to be performed during Pre-Processing of the data intake file and data content received from the Group Customer. In the Data Intake Definition, the business analyst will configure the XML schema defining the XML structure of the incoming record. If the Validations fail, the data intake process does not move forward to the next step in processing.

Components of Data Intake Profile Definition Rule

The Data Intake Profile Definition Rule is comprised of the Record XML Schema, Record XSLT, and Definition Rule XML Data.

  • The Record XML Schema provides the basis and definition of all acceptable values and constraints on the incoming data and structure of the incoming file. The Schema defines the Fields (Field Names and acceptable values) specific to Person, Client, Address, Policy, Segment, Class, and Relationship information.
  • The Record XSLT transforms the Group Customer’s data received to an acceptable format (working with the Domain Model and the file loader). Only validations related to the format will be performed at this time (not syntax validations).
  • The Intake Profile Definition Rule XML Data will be used to display the fields on the Intake Profile Screen and also used to perform Pre-Processing validations on the information / data received in the file.

Note: Please see Data Intake Profile Definition within the Rules Palette and XML configuration Guide for more details on the major components configured within this rule (Fields, Comparator Name, Calculate Changes, File Validation including Math and Validations, and Transaction Processing.

The Intake Profile Screen allows for the user to create specific Group Customer Profile instances within OIGPA using the Intake Profile Definition Rule. Each Intake Profile is a Group Customer specific instance record defined through use of the previously configured Intake Profile Definition Rule.

The list of Data Intake Definitions available will be based on the Data Intake Definitions configured by the Rules Palette and made available to the Group Customer. When the user selects a Data Intake Definition, the system will load the rule for the Data Intake Definition Rule, and present the user with all of the fields available. This is similar to the way Segments work today. The Intake Profiles Screen allows the user to change the which elements are required in the XML Schema, valid maximum/minimum ranges, etc...for each data intake profile.

The user will have the ability to override the validations done in the XML Schema when creating a Data Intake Profile. The structure of the record will be displayed in the screen, and for each element and attribute, the user will be able to change the validations for the field. Saving the Data Intake Profile will save a copy of the XML Schema to the Data Intake Profile table, with the modified validations.

The Profile Screen Rule allows the user to create / change the elements in the XML Schema are required, the valid minimums/maximums, etc... for each profile.

Pre-Processing

The Data Intake File will be evaluated against the Data Intake Profile during Pre-Processing. The evaluation determines which Data Intake Profile to use during processing. The evaluation takes the last successfully completed file and compares that to the newly received file. The results of the comparison between the incoming record and the established profile will determine the appropriate action to be taken prior to processing the file.

The comparison indicates if the following need to conditionally occur:

  • If all member records in the current intake file existed in the last successfully processed member record for that profile.

  • Calculate the differences between the current record and the content of the last successfully processed member record for that profile.

  • Determine if the record must be transformed into a standard record structure via the XSLT.

OIGPA uses a transaction for the Pre-Processing of the records within the file.

  • The transaction will run validations in terms of the expected data.
  • The transaction will calculate the changes for the records.

  • If a file comparator is not specified, it is assumed the file contains “changes only” record data. There is no need for a comparison of the last successfully processed file versus the newly received file for the purposes of identifying new or missing records.

  • If a file comparator is specified, the comparison of the last successfully processed file and the new file are evaluated and records are marked as -New/Removed..
  • After the file record differences are identified (if applicable), the file records are passed along to the XSLT and XSD schema for transformation to a standard format. Note: The records may already be in a standard format. If the record fails during validation/transformation, pre-processing of the individual records halts and an error is recorded.

  • The records are passed to a record comparator defined within the Intake Profile. If no record comparator is defined, the member record is set to a "Pending Validation" status. If the record comparator exists, the newly received record is compared to the last successfully processed record for that member. If there are differences, the record is set to "Changed" else "Unchanged" and the file status is set to "Pending Validation".

    Once the changes are calculated, the Math will run for the transaction.

  • Once the Math is complete, the ValidateExpressions business rule can determine if the record is valid. If the validation fails, the record does not progress to the final processing.

  • If the record is validated, the record will be updated and the changes stored that were calculated and correct statuses.

During processing of the file, the system uses the Unique File ID, Group Customer ID, and Intake Profile Name to locate the appropriate file for processing. Once the file is loaded into the system, the Record Transaction Processing step will begin.

Processing

The Data Intake Transaction evaluate incoming member data to determine the appropriate Client and Policy level transactions are required to update data within OIGPA. Such changes include but are not limited to: determining Class Membership, updates to existing members, creating new members, coverage changes, coverage/policy cancellations, and changes to relationships.

Once the Client and/or Policy level transaction is created an Activity Math object will be constructed within the transaction to specify the input values and the level for where the activity will be inserted and processed. Possible levels are: Company, Group Customer, Client, Plan, or Policy. Multiple activities may be constructed in the Data Intake Activity to complete all the requested changes within the file for each member record.

Within the Math section of the Data Intake Activity, sequencing is running to order the activities so the activities are processed and their respective values inserted into the database in the specified order and across multiple levels in the system.

Once all the sequences have been processed the Data Intake Activity becomes Active in the system and the next member record will begin processing.

Note: Please see ActivityArray Math Variable and Sequences Editor Tab within the Rules Palette and XML configuration Guide for more details on the major components configured within the Group Customer - Data Intake Transaction.

File Record Spawns and Rollbacks

Data Intake File Record Transactions have the ability to spawn activities on Clients and Policies. The levels for spawning are: Company, Group Customer, Plan, Client, and Policy.

Example: A Member is adding a new child to their Dental and Vision Coverage.

  • A Family Record Execution Transaction will be processed that will create the Dependent on the system.
  • A Transaction will be processed that will add the Dependent to the Dental Policy.
  • A Transaction will be processed that will add the Depended to the Vision Policy.

Note: All of these activities are executed when the File Record is processed. If the record is reversed, the individual activities generated and processed linked to the record are reversed as well.

Rollbacks of transactions created from the Data Intake Transaction will be supported back to the last successfully processed Data Intake File.

The system will track the sequence of activities that result from the parent transaction. Any subsequent spawned activities are also included in the list of activities tracked and sequenced.

Rewinding a File will begin the process of undoing all of the file record transactions executed in the file on the system. The File will appear to be rewinding to the user. Upon reversal, all activities are in the sequence are reversed (Shadowed) in the opposite order they were first executed (last processed, first reversed).

Note: During the rewinding process the system will not allow the processing of any files for the Group Customer until the File has successfully rewound.